Click Here!
home account info subscribe login search My ITKnowledge FAQ/help site map contact us


 
Brief Full
 Advanced
      Search
 Search Tips
To access the contents, click the chapter and section titles.

Oracle Performance Tuning and Optimization
(Publisher: Macmillan Computer Publishing)
Author(s): Edward Whalen
ISBN: 067230886x
Publication Date: 04/01/96

Bookmark It

Search this book:
 
Previous Table of Contents Next


Redo Log Buffer Latch Contention

The access to the redo log buffer is controlled by two types of latches: the redo allocation latch and redo copy latches.

The redo allocation latch controls the writing of redo entries to the redo log buffer. To write an entry into the redo log buffer, the user process must obtain the redo allocation latch, allocate space in the redo log buffer, and then copy the entry into the buffer. Whenever the user process has finished copying into the redo log buffer, it releases the latch, thus allowing other user processes to use the redo allocation latch.

Because only one redo allocation latch exists, only one user process can write to the log buffer at a time. The maximum amount of data that can be written into the latch is specified by the initialization parameter LOG_SMALL_ENTRY_MAX_SIZE.

If the redo entry exceeds the value specified by LOG_SMALL_ENTRY_SIZE, the user process must obtain a redo copy latch before copying into the redo log buffer. After allocating a redo copy latch, the user process can write into the buffer.

With multiple-CPU machines, you can have multiple redo copy latches. That is, you can allow simultaneous entries into the redo log buffer, which increases performance. The number of redo copy latches is determined at instance startup by the parameter LOG_SIMULTANEOUS_COPIES; the value defaults to CPU_COUNT. In a single-CPU machine, there are no redo copy latches and all access to the redo log buffer is through the redo allocation latch, regardless of size.

There are two ways of accessing both the redo allocation latch and the redo copy latches:

  Willing-to-wait. The process requests a latch; if it is not available, the process sleeps for a while and tries again later. The process continues waiting until it gets the latch.
  Immediate. The process either gets the latch or continues processing if it cannot get it.

Determining Latch Contention Problems

Latch contention can be determined by examining the dynamic performance table, V$LATCH. The significant values are given here:

  GETS: For willing-to-wait requests. The number of successful requests.
  MISSES: For willing-to-wait requests. The number of times the initial request fails.
  SLEEPS: For willing-to-wait requests. The number of times subsequent requests fail.
  IMMEDIATE_GETS: For immediate requests. The number of successful requests.
  IMMEDIATE_MISSES: For immediate requests. The number of times the request fails.

You can look for contention on latches by using the following SQL statement:

SQL> SELECT SUBSTR(name,1,20), gets, misses, sleeps, immediate_gets, immediate_misses
  2  FROM v$latch
  3  WHERE name IN ('redo allocation', 'redo copy');

SUBSTR(NAME,1,20)         GETS    MISSES    SLEEPS IMMEDIATE_GETS IMMEDIATE_MISSES
--------------------  --------  --------  -------- --------------   --------------
redo allocation           2744         0         0              0                0
redo copy                    0         0         0              0                0

If the ratio of MISSES to GETS exceeds 1 percent or the ratio of IMMEDIATE_MISSES to the sum of IMMEDIATE_MISSES and IMMEDIATE_GETS exceeds 1 percent, contention is probably affecting performance in your system.

Solving Latch Contention Problems

If latch contention is causing performance problems, there are several things you can do to try to reduce this contention.

To reduce contention on the redo allocation latch, you can reduce the size of LOG_SMALL_ENTRY_MAX_SIZE to minimize the time any user process holds the latch. This is done by reducing both the size and number of redo entries copied onto the redo allocation latch.

Resetting the value of LOG_SIMULTANEOUS_COPIES can reduce contention by adding more redo copy latches. You may see improvement by adding up to twice the number of redo copy latches as CPUs.

Another way to reduce the time a user process holds the latch is by requiring the user process to prebuild the redo entries before it obtains the latch. This prebuilt entry reduces contention on the latch by not using CPU time to build the entry while the latch is being held.

By setting the initialization parameter LOG_ENTRY_PREBUILD_THRESHOLD, any redo entry of a smaller size than this parameter must be prebuilt. The default for LOG_ENTRY_PREBUILD_THRESHOLD is 0 (that is, it requires no prebuilding).

Although redo log buffer latches are usually not a problem, they can be a source of contention under certain circumstances. You have seen how to check for latch contention and how to reduce contention if you find it. Unless you are under extremely heavy loads, it is not necessary to monitor the redo buffer latches.


Previous Table of Contents Next


Products |  Contact Us |  About Us |  Privacy  |  Ad Info  |  Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited.